Conversion de longs fichiers texte en CSV

Version imprimable

27/11/2014, 17h28
cantador

Conversion de longs fichiers texte en CSV

Bonsoir,

une exportation d'un logiciel me donne une dizaine de fichiers au format .txt.
ces derniers sont énormes (certains ont 1 million de lignes) et ne peuvent pas être complètement ouverts par EXCEL
la partie qui est digérée par celui-ci me permet de voir qu'en délimitant par tabulation uniquement
j'arrive à constituer un fichier correct pouvant ensuite être converti au format csv.
je souhaiterais pouvoir faire cette conversion en une seule fois avec Delphi7
ou en utilisant un composant.

merci
27/11/2014, 19h03
Andnotor

Je n'ai pas bien compris ta question. Tu veux représenter un certains nombre de lignes en colonnes afin de limiter le nombre de lignes ?
28/11/2014, 07h45
SergioMaster

Bonjour,

Comme Andnotor je n'ai pas bien compris

Citation:

Envoyé par cantador

la partie qui est digérée par celui-ci me permet de voir qu'en délimitant par tabulation uniquement
j'arrive à constituer un fichier correct pouvant ensuite être converti au format csv.

Par là tu veux dire : remplacer les tabs par des virgules ?
Attention à ne pas oublier les données avec espaces à mettre entre " "

En tout cas avec 1000000 de lignes je ne sais pas si TStringList aura la capacité , je ne pense pas .
a mon avis il faut traiter le fichier en plusieurs parties un peu comme ça :

Citation:

tant que pas fin de fichier de départ
lire 1000 lignes dans un TStringList
convertir dans le TStringList (voir la propriété commatext)
sauver les lignes dans fichier résultat

Une FAQ pour la piste
une petite video (Neo-Zelandaise donc english) pour le commatext
devrait mettre le pied à l'étrier
28/11/2014, 09h53
cantador

conversion de longs fichiers texte au format csv

Bonjour,

je reprends contact d'ici peu...

@+
28/11/2014, 11h03
cantador

merci pour votre attention

je précise qu'il s'agit vraisemblablement d'une exportation de tables, car les entêtes de colonne (donc les champs..)
figurent dans le fichier.. il y en a beaucoup, tous de taille différente et comportant des caractères accentués.
j'ai bien sûr cherché de mon côté..
j'ai trouvé un petit composant qui parse les fichiers texte, mais il faut renommer les champs et leurs tailles
ce qui ne m'arrange pas du tout, car rien n'est à la même longueur et ne veux pas changer le nom des champs.

les données elles sont toutes soient numériques, soit en texte majuscule.

mais il faudrait dans un premier temps, comme vous l'indiquez pouvoir mettre des " " pour les données contenant des espaces..
comment fait EXCEL pour traiter directement les tabulations sans s'occuper des blancs dans les données ?

Par là tu veux dire : remplacer les tabs par des virgules ?
Oui, c'est exactement ce que je voudrais faire, mais avec des points virgules.
remplacer #9 par #3B

et je voudrais aussi éviter les TextFile..

merci

longs fichiers texte

c'est toujours au moment où l'on pose la question que souvent on trouve une partie de la réponse...
je viens en effet de trouver un composant : Le TJvCsvDataSet qui fait tout le boulot !
enfin presque, il reste à introduire ensuite le ";".
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 procedure TForm1.Button1Click(Sender: TObject); var SL: TStringList; begin SL := TStringList.Create; try JvCsvDataSet1.Close; JvCsvDataSet1.Separator := #9; JvCsvDataSet1.Open; JvCsvDataSet1.First; while not JvCsvDataSet1.Eof do begin SL.Add(JvCsvDataSet1.FieldByName('MonChamp1').Text + ';'); // + champ2 + '; '+ champ3 + ';' + champ4 etc.. JvCsvDataSet1.Next; end; SL.SaveToFile('testR.csv'); finally SL.Free; showmessage('terminé !'); end; end;
On devrait même pouvoir concaténer le tout en faisant appel des champs dans le composant par leur index..

Si vous une meilleure solution ou même sans utiliser ce composant, je suis preneur.

merci par avance pour votre aide précieuse

suite..

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
procedure TForm1.Button1Click(Sender: TObject);
var
  SL: TStringList;
  i: integer;
  conca: string;
begin
  SL := TStringList.Create;
  try
    JvCsvDataSet1.Separator := #9;
    JvCsvDataSet1.Open;
    while not JvCsvDataSet1.Eof do
    begin
      conca := '';   
      for i := 0 to JvCsvDataSet1.FieldCount - 1 do
        conca := conca + JvCsvDataSet1.Fields[i].Text + ';';
      SL.Add(conca);
      JvCsvDataSet1.Next;
    end;
    SL.SaveToFile('testR.csv');
  finally
    SL.Free;
    showmessage('terminé !');
  end;
end;

un petit os cependant, je perds les entêtes des colonnes
j'attends vos commentaires..

28/11/2014, 14h53
cantador

suite..

aie !
Pour la plupart des fichiers, le composant plante avec un message d'erreur :

"Two many fields, or two many long string fields in this record.
You must increase the internal record size of the CsvDataSet"

le seul paramètres externe est : 80 (largeur des champs)
mais les miens font moins de 80..

merci de votre aide
28/11/2014, 16h01
Andnotor
Je ne comprends toujours pas bien ta problématique. Ce que tu nous montres là est juste un StringReplace :
Code:

1 2 3 4 5 6 7 8 with TStringStream.Create do try LoadFromFile('Before.txt'); WriteString(StringReplace(DataString, #9, ';', [rfReplaceAll])); SaveToFile('After.csv'); finally Free; end;
Pour autant que le séparateur n'apparaisse pas dans les chaînes bien sûr ;)

Citation:

Envoyé par cantador

mais il faudrait dans un premier temps, comme vous l'indiquez pouvoir mettre des " " pour les données contenant des espaces..

Les espaces ne jouent aucun rôle, seul le séparateur peut poser problème.
28/11/2014, 16h08
retwas

Sinon il est possible de créer directement ton CSV en utilisant des composants permettant de manipuler Excel (TExcelWorksheet, TExcelApplication, ..)
28/11/2014, 17h00
Barbibulle

Si j'ai bien compris ce n'est qu'un fichier texte ? Delphi gère très facielement les fichier texte, pas besoin d'utiliser un marteau piqueur (Excel) pour écraser une mouche ! (Même si ca peut marcher :aie:)

Je n'ai pas bien compris le pourquoi du comment (mais est ce utile ?)

Si j'ai compris vous avez un fichier texte de plusieurs millions de lignes que vous voulez transformer en CSV ?

Je n'ai pas compris les différents formats que vous avez le plus simple pour tout le monde c'est que vous copiez quelques lignes ici et nous dire ce que vous voulez en sortie.

Parce qu'il me semble que le problème est très simple à solutionner... Il suffit d'ouvrir le fichier texte de lire une ligne de la traiter, et de l'écrire dans un second fichier et ce jusqu'à la fin...

Pas besoin de composants ni de tout monter en mémoire pour faire ce type de moulinette...

longs fichiers texte tabulés transformés en csv

Bonjour à tous,

désolé pour le break...
et merci pour vos suggestions qui m'ont fait avancer.

je n'ai en fait que cette solution :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 procedure ReplaceChar; var F1, F2: textfile; ch: char; textfile1, textfile2: string; begin textfile1 := 'text1.txt'; textfile2 := 'test2.csv'; assignfile(F1, textfile1); reset(F1); assignfile(F2, textfile2); rewrite(F2); repeat read(F1, ch); if ch = #9 then ch := #59; write(F2, ch); until eof(F1); close(F1); close(F2); ShowMessage('terminé !'); end;
celle que je voulais éviter..:roll:
mais au final, cela marche bien (tout est nickel)
et ce n'est pas très long..

avec StringReplace, j'ai le temps de boire 5 cafés..
à noter également qu'avec D7, on ne dispose pas de la méthode LoadFromFile sur TStringStream..

mais j'aurais préféré une solution avec Stream, car je suppose que j'aurais gagné du temps de traitement.

Qu'en pensez-vous ?

01/12/2014, 15h40
Barbibulle

Je pense que si vous lisiez par ligne (readln) ou par bloc (au lieu de char un char[2000] par exemple) ça irait plus vite que caractère par caractère.

A voir si TMemoryStream supporte LoadFromFile en D7 (il me semble que oui) sinon on peut passer par deux streams (dont un TFileStream) et utiliser CopyFrom.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
var
  P    :PAnsiChar;
  PEnd :PAnsiChar;
begin
  with TMemoryStream.Create do
  try
    LoadFromFile('Before.txt');
 
    P    := Memory;
    PEnd := P +Size;
 
    while P <= PEnd do
    begin
      if P^ = ',' then
        P^ := ';';
 
      inc(P);
    end;
 
    SaveToFile('After.csv');
  finally
    Free;
  end;
end;

01/12/2014, 17h12
cantador

suite..

@Andnotor

je teste ton code..

bonne soirée

test de performance

Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 procedure TForm1.Button8Click(Sender: TObject); var P: PAnsiChar; PEnd: PAnsiChar; startTime64, endTime64, frequency64: Int64; elapsedSeconds: single; begin QueryPerformanceFrequency(frequency64); QueryPerformanceCounter(startTime64); with TMemoryStream.Create do try LoadFromFile('test.txt'); P := Memory; PEnd := P + Size; while P <= PEnd do begin if P^ = #9 then P^ := ';'; inc(P); end; SaveToFile('test2.csv'); finally Free; QueryPerformanceCounter(endTime64); elapsedSeconds := (endTime64 - startTime64) / frequency64; ShowMessage(FloatToStr(elapsedSeconds)); end; end;
avec les textfile, pour un fichier de 530 000 lignes, cela met 9 secondes
et avec un stream, le test affiche 960 ms, soit à peine une seconde !

le plus gros fichier a un peu plus de 1 million de lignes..

j'ai la chance que dans chaque colonne, les données ne sont pas très grandes.
il va falloir maintenant, faire le choix du traitement du .csv..(j'ai beaucoup lu ShailLeTroll sur le sujet..)
je n'ai en principe que de la lecture à exécuter.

ex: trouver une info, dans la nième colonne, de la nième ligne et récupérer les autres infos de l'enregistrement.
j'ai le choix entre :
- soit lire les lignes, une par une avec des fonctions chaines en détectant les ";"
- soit tout charger dans un array of array of string (si le tableau ne déclenche pas un out of memory et faire des recherches dedans
- soit importer les donnés dans des tables afin de récréer une base de données

merci de me donner votre avis avant que je me jette dans la fosse aux lions:calim2:

02/12/2014, 12h14
Barbibulle

Bonjour,

Vous auriez pu avoir un performance similaire avec votre textfile simplement en augmentant votre buffer de lecture.

Il n'y a rien de magique vous lisiez votre fichier caractère par caractère donc un accès disque à chaque lecture. L'accès disque est 10 fois plus couteux qu'un accès mémoire...

Votre Stream quand vous faites LoadfromFile va tout charger en mémoire. (ce qui n'est pas gênant sur les machines d'aujourd'hui a moins que vos fichiers ne dépasse les giga...)

Vous auriez pu également utiliser un TFileStream qui contrairement à TMemoryStream ne va pas charger tout le fichier en mémoire.

Après pour ce qui est du traitement du csv (pourquoi csv si c'est pour le transformer après ?) Un fichier à longueur fixe est lisible par Excel et présente l'avantage de pouvoir naviguer plus rapidement dedans avec delphi (par exemple pour aller à la 50000 ième ligne on n'est pas obligé de lire les 49999 lignes précédentes...)

Le choix peut se faire en fonction des besoins que vous avez envers ce fichier...

Un accès directe au nième enregistrement ? => Fichier à longueur fixe ou stringList ou table d'une base de données
Recherche de donnée selon critère ? => Le plus simple sera la table de base de données
Tri des données ?=> Le plus simple sera la table de base de données

En gros cela va dépendre de votre besoin en complexité de recherche.

traitement du csv

@Barbibulle:

Citation:

pourquoi csv si c'est pour le transformer après ?

oui, tu as raison, mais je le sens mieux avec des ";" qu'avec des tabulations..
Le TMemoryStream me va bien.

Citation:

Un fichier à longueur fixe est lisible par EXCEL et présente l'avantage de pouvoir naviguer plus rapidement dedans avec delphi (par exemple pour aller à la 50000 ième ligne on n'est pas obligé de lire les 49999 lignes précédentes...)

oui, mais ma version EXCEL ne peut pas charger plus de 65535 lignes..(à moins que j'ai loupé quelque chose..)

il n'y guère que TStringList qui charge les fichiers sans râler,
les autres composants que j'ai trouvés suffoquent tous..
l'idéal, aurait été de pouvoir trouver un composant Dataset qui charge les fichiers et du coup,
j'aurais pu ensuite travailler sur une table virtuelle (avec locate, lookup etc..)

je viens de faire ce test avec un énorme tableau :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 unit Unit1; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls; type TForm1 = class(TForm) Button1: TButton; procedure Button1Click(Sender: TObject); private { Déclarations privées } public { Déclarations publiques } end; var Form1: TForm1; TMEDDI: array of array of string; implementation {$R *.dfm} procedure TForm1.Button1Click(Sender: TObject); var nbl, nbc, i, j: integer; begin try nbl := 1000000; nbc := 50; SetLength(TMEDDI, nbl, nbc); for i := 0 to (nbl - 1) do for j := 0 to (nbc - 1) do TMEDDI[i, j] := 'TOTOTATATITI'; finally ShowMessage(TMEDDI[nbl - 1, nbc - 1]); end; end; end.
avec les bêtes de course d'ordi qu'on dispose maintenant..
résultat il m'affiche bien le dernier élément stocké.

mais est ce bien raisonnable ?

Citation:

Le choix peut se faire en fonction des besoins que vous avez envers ce fichier...
En gros cela va dépendre de votre besoin en complexité de recherche.

oui:D..mais en fait, c'est un peu plus compliqué que ça..
les besoins, c'est moi qui vais les créer !
et donc, je suis obligé d'envisager quasiment tous les cas de figure
du moins, dans un premier temps.
le seul critère qui m'importe c'est la vitesse d'exécution des actions (comme dab..)

donc, meilleure technique
pour une lecture avec recherche d'éléments
pour une écriture
?

02/12/2014, 16h07
Barbibulle

Si tes besoins sont indéterminés ou du moins tu ne veux pas les limiter, je dirais que la meilleurs solution c'est de faire appel (non pas à un amis) aux services d'une base de données.

Les moteurs des bases de données sont spécialisées dans la manipulation des données, le tri, la recherche, la sélection...

J'aurai tendance à te dire de ne pas réinventer la roue (surtout quand il existe des roues qui fonctionnent bien :p )

Je travail pas mal avec firebird, qui a une version embarquée si tu ne veux pas installer la partie serveur et travailler uniquement en local.

Sinon une autre piste serait de trouver un composant de type table en mémoire.

Genre TclientDataset, ou dxMemData de chez devexpress ou ... il en existe pas mal d'autres

Sinon as tu regardé http://fsoriano.developpez.com/artic...ataset/delphi/ ?

Ou encore le composant gratuit Jedi : TJvCsvDataSet qui permet de lire un fichier csv (ou même ton fichier texte séparé par des tabulations) et après tu y accèdes via les composants DB, les fields etc...
http://wiki.delphi-jedi.org/wiki/JVC...:TJvCsvDataSet

Qui a mon avis pourrait être ta meilleure piste :p (tu n'as même plus besoin de ta phase de conversion des tab en ; )
02/12/2014, 16h27
cantador

suite

Firebird et le TdxMemData, je connais..;)

mais le TMemoryDataSet

oui oui cela me plait bien, cette nouvelle classe..:D

je vais tester tout ça..

@+
02/12/2014, 16h30
Barbibulle

Citation:

Envoyé par Barbibulle

Ou encore le composant gratuit Jedi : TJvCsvDataSet qui permet de lire un fichier csv (ou même ton fichier texte séparé par des tabulations) et après tu y accèdes via les composants DB, les fields etc...
http://wiki.delphi-jedi.org/wiki/JVC...:TJvCsvDataSet

Qui a mon avis pourrait être ta meilleure piste :p (tu n'as même plus besoin de ta phase de conversion des tab en ; )

Je testerai ce dernier en premier ! (enfin je me comprend :aie:)
02/12/2014, 17h18
cantador

TJvCsvDataSet

j'ai déjà testé le TJvCsvDataSet
et il plante, car trop de ceci ou de celà..
@+
02/12/2014, 19h07
Barbibulle

Effectivement, je n'ai pas la dernière version du composant (et sourceforge est en carafe) mais il consomme énormément de mémoire. J'ai testé sur une fichier texte d'un million de lignes (environ 12 Mo seulement) et il m'a gentiment fait un "Out of memory". L'application est monté a plus d'un Go puis est descendu à 100Mo pour remonter lentement vers les 400Mo et me lacher le message...
03/12/2014, 11h30
cantador

suite...

Oui, dommage que le TJvCsvDataSet plante car c'était le plus aboutit.
peut-être y a t-il un moyen de modifier ce composant afin de lui faire déborder ses limites ?

le TdxMemData, quant à lui, fonctionne à l'envers de ce que je souhaite faire.
En effet, il faut d'abord créer les colonnes et ensuite faire un load des données m'obligeant donc
à détecter, dans un premier le nombre et le nom des champs, puis avec une procédure les créer dans le TdxMemData
et enfin, importer les données avec un load, mais bien sûr sans la première ligne des champs !
ce qui au final, n'est pas très pratique.

et à propos de la classe TMemoryDataSet, le lien de téléchargement ne fonctionne plus..:(
Si on résume, il ne me reste plus grand chose à part créer des tables.
A ce propos, comme, j'ai une quinzaine de fichiers, ce qui est peu, mais en revanche, cela représente beaucoup de champs
plusieurs centaines environ, et cela me dérange de me coltiner leurs créations dans Firebird.
je peux bien sûr créer un SQL, mais le top aurait été de faire un datapump qui créer automatiquement les champs et les données dans Firebird
comme le fait ACCESS.
il y en a un EMS DataPump mais payant:aie:

?
03/12/2014, 12h18
Barbibulle

Citation:

Envoyé par cantador

Oui, dommage que le TJvCsvDataSet plante car c'était le plus aboutit.
peut-être y a t-il un moyen de modifier ce composant afin de lui faire déborder ses limites ?

le TdxMemData, quant à lui, fonctionne à l'envers de ce que je souhaite faire.
En effet, il faut d'abord créer les colonnes et ensuite faire un load des données m'obligeant donc
à détecter, dans un premier le nombre et le nom des champs, puis avec une procédure les créer dans le TdxMemData
et enfin, importer les données avec un load, mais bien sûr sans la première ligne des champs !
ce qui au final, n'est pas très pratique.

et à propos de la classe TMemoryDataSet, le lien de téléchargement ne fonctionne plus..:(
Si on résume, il ne me reste plus grand chose à part créer des tables.
A ce propos, comme, j'ai une quinzaine de fichiers, ce qui est peu, mais en revanche, cela représente beaucoup de champs
plusieurs centaines environ, et cela me dérange de me coltiner leurs créations dans Firebird.
je peux bien sûr créer un SQL, mais le top aurait été de faire un datapump qui créer automatiquement les champs et les données dans Firebird
comme le fait ACCESS.
il y en a un EMS DataPump mais payant:aie:
?

De toute façon dxmemdata ne peut pas lire directement un fichier csv il faut le lire toi et le mettre au format accepté par dxmemdata oubien alimenter le dxmemdata directement par des .insert ou .insertrecord.

Pour le TJvCsvDataSet les sources sont disponibles, a voir les problèmes de licence.
Mais pour lui aussi il faut définir les champs.

Si tu n'as qu'une quinzaine de type de fichier pour une centaine de champs ce n'est pas la mort non plus.

L’inconvénient de créer dynamiquement tes tables / colonnes c'est qu'apres il te faudra un requeteur dynamique pour consulter etc
03/12/2014, 12h35
Barbibulle

Il existe aussi une solution avec les drivers ODBC.

Il existe des drivers ODBC pour fichier texte csv

C'est peut être une piste à explorer.
03/12/2014, 14h56
cantador

suite..

Citation:

Pour le TJvCsvDataSet les sources sont disponibles, a voir les problèmes de licence.
Mais pour lui aussi il faut définir les champs.

si, si il les détectent..mais plante car trop de machin..

Citation:

L’inconvénient de créer dynamiquement tes tables / colonnes c'est qu'apres il te faudra un requeteur dynamique pour consulter etc

oui, une fois les tables et champs crées, le boulot n'est pas terminé..
il reste les clés, les index , les liens, les triggers, les generators etc..
mais pour ma part, ça m'enlève quand même une belle épine du pied.
j'ai trouvé un XMLWizard d'allure assez sympa..mais chatouilleux sur la nature des données..
et je vais tester les drivers ODBC.
sinon, je vais développer une appli qui détecte les colonnes, et crée dynamiquement les tables.
je te remercie pour cette discussion qui a bien fait avancer les choses.
je mets résolu
@bientôt